Skip to content

[do not merge] Issues with TASTY - dotty pickling/unpickling #1202

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

[do not merge] Issues with TASTY - dotty pickling/unpickling #1202

wants to merge 1 commit into from

Conversation

VladimirNik
Copy link
Contributor

After checking (pickling/unpickling) src/dotty:

  • There are 10 files that have different trees representations after unpickling (string representation).
  • For each case I added sample file representing issue in addition to original source file from Dotty (files Fail1.scala - Fail10.scala)
  • I checked each sample file with FromTasty: 6 files can be compiled and checked with -Ycheck:all, 4 files have issues during compilation/checking.

Compilation issues:

1) Issue with private field access (val Unknown in object Test) from class Test (Fail3.scala):

class Test() {
  import Test._
  val myStatus = Unknown
}
object Test {
  private val Unknown: Int = 0
}

Unpickling with FromTasty results in:

assertion failed: private getter Unknown in object Test$ in null 
accessed from constructor Test in class Test in Simple(Fail3.scala)

Similar code is in: dotty/tools/dotc/core/Types.scala


2) Issue with var parameter in class (Fail7.scala):

class Fail7(var in: Int)

Unpickling with FromTasty results in:

error: class Test needs to be abstract, since 
<accessor> var in_=: (x$1: Int)Unit is not defined
(Note that an abstract var requires a setter in addition to the getter)

#### **-Ycheck:all issues**

3) Code example (Fail1.scala):

class Test[T] {
  def testMethod: Unit =
    new Foo(this)
}
class Foo[T] {
  def this(ct: Test[T]) = this()
}

Differences (in def testMethod). Such expression before pickling:

<<new Foo:Foo>:([T](ct: Test[T])Foo[T])>[T]

after unpickling becomes:

<<new Foo:Foo>:([T = Foo @UnsafeNonvariant#T](ct: Test[Foo @UnsafeNonvariant#T])Foo[T])>[T]

Unpickling with FromTasty using -Ycheck:all results in:

*** error while checking Simple(Fail1.scala) after phase frontend ***
java.lang.AssertionError: assertion failed: error at Simple(Fail1.scala):2
type mismatch:
 found   : Test[T(in Test)](Test.this)
 required: Test[Foo @UnsafeNonvariant#T(in Foo)]
tree = This(Test)

Similar code is in: dotty/runtime/vc/VCPrototype.scala


4) Code example (Fail5.scala):

class Fail5 {
  val someClass: Class[_] = ???
  val resultMethod = someClass.getMethod("result")
}

Differences in types (in val resultMethod). Such expression before pickling:

    val resultMethod: Method = 
        this:Fail5.someClass.getMethod:((x$0: String, x$1: Class[_]*)Method)>(
            <"result":String>,
            <<[ : java.lang.Class[_]]:scala.Array[java.lang.Class[_]]>: ...

after unpickling becomes:

    val resultMethod: Method = 
        this:Fail5.someClass.getMethod:((x$0: String, x$1: Class[_]*).Method)>(
            <"result":String("result")>,
            <<[ : java.lang.Class[_]]:scala.collection.Seq[java.lang.Class[_]]>: ...

The difference is that the type for x$1 arg changes from scala.Array to scala.collection.Seq

Unpickling with FromTasty using -Ycheck:all results in:

*** error while checking Simple(Fail5.scala) after phase frontend ***
java.lang.AssertionError: assertion failed: error at Simple(Fail5.scala):2
type mismatch:
 found   : scala.collection.Seq[Class[_]]
 required: Array[Class[_]]

Similar code is in: dotty/tools/dotc/repl/CompilingInterpreter.scala

@DarkDimius
Copy link
Contributor

In 4) Seems that JavaSeqLiteral was unpicked as normal SeqLiteral.

@odersky odersky mentioned this pull request Apr 7, 2016
Merged
odersky referenced this pull request Apr 16, 2016
@odersky
Merge pull request #1211 from dotty-staging/fix-#1202
3ef4115 
Fix Tasty errors
@odersky
Copy link
Contributor

odersky commented Apr 17, 2016 •
edited
Loading

@VladimirNik Do we need to keep this still open?

@VladimirNik
Copy link
Contributor Author

@odersky No, I think we can close it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@VladimirNik @DarkDimius @odersky